bun test --files-from: skip a UTF-8 byte order mark at the start of the list - #48257

Repro

for t in a b c; do printf 'import { test, expect } from "bun:test";\ntest("in %s", () => { expect(1).toBe(1); });\n' $t > $t.test.ts; done
printf '\xef\xbb\xbf./a.test.ts\n./b.test.ts\n./c.test.ts\n' > list.txt
bun test --files-from=./list.txt

I ran the repro on a debug build of main, on a local release build of main, and on the canary build 1.4.4-canary.1+2596ac5d3.

Tests

• --files-from skips a UTF-8 byte order mark at the start of the list: four lists (paths, names with CRLF, an absolute first path, two lists). Each has an unlisted file that must not run.
• a list that holds only a byte order mark lists no test files.
• U+FEFF after the start of the list is a character of the name: two lists. The first holds the mark, a.test.js, then a file whose name really starts with U+FEFF. Both run. The second has no mark and lists that file with ./ before the name. It passes on main too. These tests state the rule that only byte 0 is a mark, and hold the ./ form.
• The tests run one after another. In a debug build, six bun test child processes at once take more than 5 seconds each.
• test/aot/fuzz/grids/runner-suites-flags.ts runs this file with --aot child runs. Its files-from share passes with a release build of this PR and fails with a release build of main.
• I ran Linux x64 only. By a read of the Windows and macOS path code, no step changes a U+FEFF in a path, and test/cli/run/run-unicode.test.ts already uses U+200B in paths on all platforms.

Measurements

Two local release builds from one toolchain and one build directory: main 2596ac5, and the same tree with this change.

• Instructions, unmarked list of 3,052 lines, a run that stops after the list is parsed (bun test unit --files-from=big.txt): medians 926,136 and 926,138 instructions:u over 5 interleaved runs. The spread within one build is 7 to 13, so the delta of 2 is below the noise.
• Added code (objdump of bun_runtime::cli::arguments::parse, where the function is inlined): 10 instructions (4 compares, 4 branches, 2 adds). An unmarked list runs 4 of them.
• Marked list of 3,052 lines: 926,283 to 926,145 instructions. The first line no longer gets the ./ prefix.
• Size: size reports text 137,931,057, data 124,128, bss 1,861,880 for both builds. nm -S: arguments::parse 25,874 to 25,922 bytes. It is the only one of 191,938 symbols whose size differs. No symbol is added.
• Allocator calls in the parse-only run (gdb hit counts): mi_malloc 3,076, mi_realloc 12, mi_zalloc 3, on both builds, for the unmarked and the marked list. parse has 462 call instructions in both builds.
• Syscalls (gdb catch syscall): the marked 3-file list makes 1 openat with the mark in the path on main and 0 with this PR. openat on a.test.ts: 0 to 3. Total openat: 25 to 27, equal to the unmarked control. The parse-only run makes 95 syscalls on both builds.
• A name that really starts with U+FEFF, in an unmarked list. Bare on line 1: main runs that file, this PR runs x.test.ts if it exists, else passes the line over (2 files to 1, exit 0). With ./ on line 1: no change. Bare on line 2: no change.
• Test time: 7 more bun test child processes in files-from.test.ts (8 before), about 2 seconds in a debug build.
• --shard membership changes for a marked list, because the list has one more file. With four files, shard 1/2 ran b and d on main. It runs a and c with this PR.

Not changed here

• A mark at the start of a later line (two marked lists joined byte for byte) stays part of that path. The file is passed over in silence, as any missing path is. bun test: report each path argument that selects no test file and exit 1 #44017 (for bun test exits 0 and silently skips a nonexistent ./-prefixed path when another path matches #44002) makes a missing path an error.
• A UTF-16 list, which Windows PowerShell 5.1 writes with >, still fails. A release build exits 1 with error: ModuleNotFound resolving "<cwd>/\0.\0/\0b..." and runs no test. Peak memory grows with lines times files: 38 MB, 71 MB, 198 MB for 200, 400, 800 lines in a folder of as many files. A debug build panics with ZStr::as_cstr: interior NUL would truncate the C view.
• A line with a NUL byte reaches open. resolver, process.dlopen: do not open a path that contains a null byte #43341 (open) refuses such a path. I sent the UTF-16 repro to that work.
• Other line readers that split raw bytes, seen by grep and not traced: src/lint/driver/fmt/editorconfig.rs:370, src/install/migration.rs:385, src/install/yarn.rs:248, src/install/PackageManager/patchPackage.rs:591, src/runtime/webview/ChromeProcess.rs:1133.
• No docs change: docs/test/discovery.mdx names no encoding for the list.
• This PR touches no file of bun test: report each path argument that selects no test file and exit 1 #44017.

Self-review concerns not taken

• Write the mark as a Buffer of EF BB BF. The tests fail without the fix, which shows the bytes are on disk.
• Add the mark plus CRLF as a second empty list. The rule is the same, and it adds a child process.